home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Apr 88 / re MacApp Failure Mechanism 4⁄6 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.4 KB  |  36 lines  |  [TEXT/GEOL]
  1. Item    0425720                         6-April-88        12:44
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     N0658                           ESL, Robert Penland, ASC
  6.  
  7. cc:     MACAPP$                         MacApp Interest List
  8.  
  9. Sub:    re MacApp Failure mechanism
  10.  
  11. A failure handler can do a non-local GOTO to branch back into the main control
  12. flow.  That is what happens in the main event loop of MacApp; if a failure is
  13. caught, MacApp puts up the alert and branches back into the event loop to get
  14. the next event.
  15.  
  16. You must be careful to branch to a point after the Success call, since if the
  17. failure handler has been called already, then it doesn't need to be removed
  18. from the failure stack with the Success call.
  19.  
  20. If you just change the error code in your handler to noErr, then the failure
  21. will still propagate up the stack, but when it reaches the top, MacApp will
  22. assume that the error message has already been displayed.  In your particular
  23. case, this is probably not what you want.
  24.  
  25. You could have OpenAppleTalk return an error code (what it seems to do now), or
  26. it could just signal failure and assume that the caller will catch the error.
  27.  
  28. Some programs might require AppleTalk, so an error from OpenAppleTalk should
  29. cause the program to quit.  If you do signal a failure, you should define a
  30. message value that indicates you were trying to open AppleTalk.  You might also
  31. need strings for the errors that could be returned.
  32.  
  33. Larry
  34.  
  35.  
  36.